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This is in response to the appeal brief filed 08 July 2004. 
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(1) Real Party in Interest 

A statement identifying the real party in interest is contained in the brief. 

(2) Related Appeals and Interferences 

A statement identifying the related appeals and interferences which will directly affect or 
be directly affected by or have a bearing on the decision in the pending appeal is contained in the 
brief 

(3) Status of Claims 

The statement of the status of the claims contained in the brief is correct. 

(4) Status of A mendments After Final 

No amendment after final has been filed. 

(5) Summary of Invention 

The summary of invention contained in the brief is correct. 

(6) Issues 

The appellant's statement of the issues in the brief is correct. 

( 7) Grouping of Claims 

The rejection of claims 1-36 and 38-54 stand or fall together because appellant's brief 
does not include a statement that this grouping of claims does not stand or fall together and 
reasons in support thereof. See 37 CFR 1.192(c)(7). 

(8) Claims Appealed 

The copy of the appealed claims contained in the Appendix to the brief is correct. 

(9) Prior Art of Record 

6,012,096 LINK 01-2000 
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6,321,264 FLETCHER et al. 1 1-2001 

6,625,477 ROSSMAN 08-2002 

6,621,834 SCHERPBEER et al 09-2003 

6,141,705 AN AND et al. 10-2000 

6,370,599 ANAND et al. 04-2002 

6,721,872 DUNLOP et al. 04-2004 

6,064,649 JOHNSON 05-2000 

Comer, Douglas E. "Internetworking with TCP/IP Principles, Protocols, and Architecture" 

volume 1, 1995. 

(1 0) Grounds of Rejection 

The following ground(s) of rejection are applicable to the appealed claims: 

Claims 1-29, 31-36 and 38-54 were rejected under 35 U.S.C. 103(a) over Link. This 

rejection is set forth in a prior Office Action, mailed on 03 June 2004. 

Claim 30 was rejected under 35 U.S.C. 103(a) over Link in view of Fletcher. This 

rejection is set forth in a prior Office Action, mailed on 03 June 2004. 

(11) Response to Argument 

In response to the Applicant's allegation that Link teaches away from using the 
transmission control protocol, hereinafter TCP, by disclosing the user datagram protocol, 
hereinafter UDP, without mentioning TCP in any embodiments, the Examiner disagrees. MPEP 
2123 states that: 

Disclosed examples and preferred embodiments do not constitute a teaching away from a broader 
disclosure or nonpreferred embodiments. 

See also In re Susi, 440 F.2d 442, 169 USPQ 423 (CCPA 1971). 
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Link discloses examples and preferred embodiments using UDP and makes no statement 
excluding the use of TCP, accordingly Link does not teach away from using TCP. 

In response to the Applicant's arguments that UDP and TCP are not interchangeable, the 
Examiner disagrees. As stated in the Office Action of 03 June 2004, both TCP and UDP are 
Transport Layer Protocols, Layer 4 of the OSI Model. Transport Layer Protocols establish, 
maintain, and tear down end-to-end connections and are responsible for error recovery and flow 
control. Both TCP and UDP have similar information in their headers, information which 
includes the source and destination addresses, source and destination ports, and flags. The 
difference between UDP and TCP is that UDP is a connectionless-oriented protocol while TCP is 
a connection-oriented protocol. According to http://www.pcwebopaedia.com, a connectionless 
protocol simply puts the message on the network with the destination address and hopes that it 
arrives, while a connection-oriented protocol requires a channel to be established between the 
sender and receiver before any messages are transmitted and verifies that every packet of data 
sent is received at the receiver's end. 

Additionally, several patents disclose that UDP and TCP are interchangeable. For 
example, U.S. Patent No. 6,625,477 discloses several embodiments where UDP can be used 
instead of TCP and vice versa at columns 26, line 23 to column 27, line 64. Additionally, U.S. 
Patent No. 6,621,834 discloses packet delivery guarantees by using TCP instead of UDP in the 
abstract. 

In order to rely on equivalence as a rationale supporting an obviousness rejection, the 
equivalency must be recognized in the prior art, and cannot be based on applicant's disclosure or 
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the mere fact that the components at issue are functional or mechanical equivalents. See In re 
Ruff, 256 F.2d 590, 1 18 USPQ 340 (CCPA 1958); see MPEP 2144.06. 

Since UDP and TCP are both Transport Layer Protocols, with similar properties, and the 
fact that several patents indicate that TCP can be used instead of UDP show that the two 
protocols are equivalents and therefore interchangeable. 

Furthermore, there are three possible sources for a motivation to combine references: the 
nature of the problem to be solved, the teachings of the prior art, and the knowledge of persons 
of ordinary skill in the art. In re Rouffet, 149 F.3d 1350, 1357, 47 USPQ2d 1453, 1457-58 (Fed. 
Cir. 1998). 

The prior art, U.S. Patent Nos. 6,625,477 and 6,621,834, disclose that UDP and TCP are 
interchangeable, as well as knowledge available to persons of ordinary skill in the art, Chapters 
12 and 13 of Internetworking with TCP/IP by Douglas E. Comer, provide motivation to 
modify the Link reference. 

The prior art can be modified or combined to reject claims as prima facie obvious as long 
as there is a reasonable expectation of success. In re Merck & Co., Inc., 800 F.2d 1091, 231 
USPQ 375 (Fed. Cir. 1986). See MPEP 214.02. 

There would be a reasonable expectation of success by swiping UDP out for TCP, 
because both protocols are used to transmit data using similar properties. 

The strongest rationale for combining references is a recognition, expressly or impliedly 
in the prior art or drawn from a convincing line of reasoning based on established scientific 
principles or legal precedent, that some advantage or expected beneficial result would have been 
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produced by their combination. In re Sernaker, 702 F.2d 989, 994-95, 217 USPQ 1, 5-6 (Fed. 
Cir. 1983). See MPEP 2144. 

One would be motivated to use TCP instead of UDP, because TCP ensures delivery of 
the data packet. This is disclosed in the abstract of U.S. Patent No. 6,621,834, as well as 
Chapters 12 and 13 of Internetworking with TCP/IP by Douglas E. Comer, especially in 
Chapter 12 where Comer states: 

The User Datagram Protocol (UDP) provides an unreliable connectionless delivery service using IP to 
transport messages between machines. 

As per the Applicant's allegation that Link would have not included the steps of inserting 
the first TCP destination port as a second TCP source port in the second data packet; inserting 
the first TCP source port as a second TCP destination port in the second data packet, the 
Examiner disagrees. Link teaches a response packet in at least the abstract, figures 4 and 7b, 
column 5, lines 1 1-43, and column 6, line 66 to column 7, line 13 which states: 

If the received packet is an initial "ping" packet 82 sent from a remote client (e.g. client 1), then step 902 
branches to step 904 to handle the packet. For example, as shown in FIG. 7 A, client2 receives such a 
packet 82 from clientl, whereby step 902 of client2's pingee thread recognizes the type as being a "ping" 
and branches to step 904. At step 904, the client2's pingee thread modifies the type filed of the packet to a 
response packet type (field 84d of FIG. 7B) and puts client2's current local tick timestamp into pingee- 
pinger bits 84e of the response packet 84 (FIG. 7B). Client2 then send the response packet 84 to clientl. 
Note that client l's timestamp is left intact. Also, it should be noted that it is considered equivalent for 
client2 to alternatively create its own, new response packet, and copy client l's information into the 
response packet before sending the response. 

The response packet would have to take the first destination port to make as the source port of 

the response packet, just as it would have to make the first source port the destination port of the 

response packet. 

The process disclosed by Link and the instant patent application is analogous to sending 
and receiving a letter via the United States Postal Service. A first letter being drawn to the first 
data packet includes a return address, which includes the sender's name and address being 
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equivalent to the source port and source address of the first packet (sent from clientl). The first 
letter also includes a destination address, which includes a recipient's name and address being 
equivalent to the destination port and the destination address of the packet (received at client2). 
The respective addresses are drawn to the source and destination addresses as they give a broader 
description of where the data is originating and being transmitted. The names of the addressees 
are drawn to the source and destination ports, respectively, as they give a more detailed 
description of where the information is being directed. Therefore in order to respond to the first 
letter, the original return address becomes the destination address, while the original destination 
address becomes the return address (sending from client2 back to clientl). 

In response to the Applicant's allegation that Link does not disclose a first data packet 
comprising a first time stamp indicating a first time when the first data packet was transmitted 
and inserting the first time stamp as a second time stamp in the second data packet, wherein the 
second time stamp is for indicating a second time when the second data packet is transmitted, the 
Examiner disagrees. 

Figure 7a, block 82f, clearly indicates that Link discloses a first data packet comprising a 
first time stamp indicating a first time when the data packet was transmitted. Link further 
discusses this in column 6, lines 19-52, specifically stated as: 

At step 802, for each IP address in the subset, the pinger thread 68 puts a local timestamp into the Pinger - 
Pinger tick field 82f of a Ping-type packet 82 (FIG 7 A), and sends the packet to the remote machine at that 
IP address. 

Link discloses a first data packet comprising a timestamp indicating a first time when the first 
data packet was transmitted. 

Link discloses inserting the first time stamp as a second time stamp in the second data 
packet as evident by Figure 7b, block 84f and column 7, lines 1-13, specifically: 
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Client2 then sends the response packet 84 to client 1. Note that client l's timestamp is left intact. Also, it 
should be noted that it is considered equivalent for client2 to alternatively create its own, new response 
packet, and copy client 1 's information into the response packet before sending the response. 

Link also discloses wherein the second time stamp is for indicating a second time when the 

second data packet is transmitted as shown by figure 7b, block 84e, as well as column 7, lines 1- 

13, specifically: 

At step 904, the client2's pingee thread modifies the type field of the paket to a response packet type (field 
84d of FIG. 7B) and puts client2's current local tick timestamp into pingee-pinger bits 84e of the response 
packet 84 (FIG. 7B). 

Therefore, Link discloses the limitation of inserting the first time stamp as a second time stamp 
in the second data packet, wherein the second time stamp is for indicating a second time when 
the second data packet is transmitted as seen by the cited sections above. 

With regards to the Applicant's arguments that Link does not disclose a data validity 
portion for validating the incoming data packet, the Examiner disagrees. The Applicant is 
correct in pointing out that the Examiner cites figures 1, block 53 and 5, block 80a, in addition to 
column 4, lines 4-3 1 and column 6, lines 19-33 as to the teaching of a data validity portion for 
validating incoming data packets. The cited sections of Link point to a network interface card, 
otherwise known as a NIC. Network interface cards are used to validate incoming data packets, 
examples of this can be seen in at least U.S. Patent Nos. 6,141,705 and 6,370,599, therefore Link 
discloses a data validity portion (in this case the NIC) for validating incoming data packets. 

The Examiner agrees that Link does not use the terms field programmable gate array, 
otherwise known as FPGA, but disagrees with the Applicant's allegation that they are not a part 
of the Link invention. U.S. Patent Nos. 6,721,872 and 6,064,649 provide at least two examples 
of field programmable gate arrays being used in network interface cards, a well-known and 
common practice in the art. Therefore Link discloses various portions are located within field- 



Application/Control Number: 09/591,080 Page 9 

Art Unit: 2131 

programmable gate arrays by disclosing the use of computer add-in cards, specifically a network 
interface card in this case. 

As per the Applicant's allegations that Link does not disclose validating the first 
destination value, the Examiner disagrees. The cited portions of Link disclose adding and 
removing IP addresses as clients enter and leave the zone lobby. The Examiner quotes the cited 
section as validating IP addresses by verifying whether a client is still in the zone lobby or not. 

Regarding the Applicant's allegations that Link does not teach checksums or TCP flags, 
the Examiner agrees. As shown above the Examiner has established a prima facie case of 
obviousness for using TCP instead of UDP. The Examiner contends that the Applicant is 
claiming features inherent to TCP and cites various sections of "Internetworking with TCP/IP 
Principles, Protocols, and Architectures" by Douglas E. Comer. Thus, if TCP is being used, 
checksums and TCP flags become a part of the data packet header as seen in the cited sections of 
"Internetworking with TCP/IP Principles, Protocols, and Architectures" by Douglas E. Comer. 

For the above reasons, it is believed that the rejections should be sustained. 
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